Vzor Saga: Implementácia distribuovaných transakcií pre mikroslužby

Vo svete mikroslužieb môže byť udržiavanie konzistencie dát naprieč viacerými službami významnou výzvou. Tradičné ACID transakcie (Atomicita, Konzistencia, Izolácia, Trvácnosť), bežne používané v monolitických aplikáciách, sú často nevhodné pre distribuované prostredia. Práve tu prichádza na rad vzor Saga, ktorý poskytuje robustné riešenie na správu distribuovaných transakcií a zabezpečenie integrity dát naprieč mikroslužbami.

Čo je vzor Saga?

Vzor Saga je návrhový vzor používaný na správu sekvencie lokálnych transakcií naprieč viacerými mikroslužbami. Poskytuje spôsob, ako dosiahnuť eventuálnu konzistenciu, čo znamená, že hoci dáta môžu byť dočasne nekonzistentné, nakoniec sa zosúladia do konzistentného stavu. Namiesto spoliehania sa na jedinú, atomickú transakciu, ktorá zahŕňa viacero služieb, vzor Saga rozdeľuje transakciu na sériu menších, nezávislých transakcií, z ktorých každú vykonáva jedna služba.

Každá lokálna transakcia v rámci Saga aktualizuje databázu jednej mikroslužby. Ak jedna z transakcií zlyhá, Saga vykoná sériu kompenzačných transakcií na zrušenie zmien vykonaných predchádzajúcimi transakciami, čím efektívne vráti späť celú operáciu.

Prečo používať vzor Saga?

Niekoľko faktorov robí zo vzoru Saga cenný nástroj na správu transakcií v architektúrach mikroslužieb:

• Voľné prepojenie (Decoupling): Sagy podporujú voľné prepojenie medzi mikroslužbami, čo im umožňuje vyvíjať sa nezávisle bez ovplyvnenia ostatných služieb. Toto je kľúčová výhoda architektúr mikroslužieb.
• Škálovateľnosť: Vyhýbaním sa dlhotrvajúcim, distribuovaným transakciám Sagy zlepšujú škálovateľnosť a výkon. Každá mikroslužba môže spravovať svoje vlastné transakcie nezávisle, čo znižuje spory a zvyšuje priepustnosť.
• Odolnosť: Sagy sú navrhnuté tak, aby boli odolné voči zlyhaniam. Ak transakcia zlyhá, Saga môže byť vrátená späť, čím sa zabráni nekonzistentnosti dát a zabezpečí sa, že systém zostane v konzistentnom stave.
• Flexibilita: Vzor Saga poskytuje flexibilitu pri správe zložitých obchodných procesov, ktoré zahŕňajú viacero služieb. Umožňuje vám definovať sekvenciu transakcií a kompenzačné akcie, ktoré sa majú vykonať v prípade zlyhania.

ACID vs. BASE

Pochopenie rozdielu medzi ACID a BASE (Basically Available, Soft state, Eventually consistent) je kľúčové pri rozhodovaní, či použiť vzor Saga.

• ACID (Atomicita, Konzistencia, Izolácia, Trvácnosť): Zaručuje, že transakcie sú spracované spoľahlivo. Atomicita zaisťuje, že buď všetky operácie v rámci transakcie uspejú, alebo žiadna. Konzistencia zaisťuje, že transakcia pretransformuje databázu z jedného platného stavu do druhého. Izolácia zaisťuje, že súbežné transakcie si navzájom nezasahujú. Trvácnosť zaisťuje, že akonáhle je transakcia potvrdená, zostane tak aj v prípade zlyhania systému.
• BASE (V podstate dostupné, Mäkký stav, Eventuálne konzistentné): Toto je odlišný prístup určený pre distribuované systémy. V podstate dostupné znamená, že systém je dostupný väčšinu času. Mäkký stav znamená, že stav systému sa môže časom meniť, aj bez vstupu. Eventuálne konzistentné znamená, že systém sa nakoniec stane konzistentným, keď prestane prijímať vstupy. Vzor Saga je v súlade s princípmi BASE.

Dve hlavné implementačné stratégie Saga

Existujú dva hlavné spôsoby implementácie vzoru Saga: Choreografia a Orchestrácia.

1. Saga založená na choreografii

V Sage založenej na choreografii sa každá mikroslužba zúčastňuje na Sage tým, že počúva udalosti publikované inými mikroslužbami a podľa toho reaguje. Neexistuje žiadny centrálny orchestrátor; každá služba pozná svoje povinnosti a vie, kedy má vykonať svoje akcie.

Ako to funguje:

1. Saga začína, keď mikroslužba publikuje udalosť signalizujúcu začiatok transakcie.
2. Ostatné mikroslužby sa prihlásia na odber tejto udalosti a po jej prijatí vykonajú svoju lokálnu transakciu.
3. Po dokončení svojej transakcie každá mikroslužba publikuje ďalšiu udalosť signalizujúcu úspech alebo zlyhanie svojej operácie.
4. Ostatné mikroslužby počúvajú tieto udalosti a podnikajú príslušné kroky, buď pokračujú na ďalší krok v Sage, alebo iniciujú kompenzačné transakcie, ak dôjde k chybe.

Príklad: Vytvorenie objednávky v e-shope (Choreografia)

1. Služba pre objednávky: Prijme novú požiadavku na objednávku a publikuje udalosť `ObjednávkaVytvorená`.
2. Skladová služba: Prihlási sa na odber `ObjednávkaVytvorená`. Po prijatí udalosti skontroluje zásoby. Ak sú dostatočné, rezervuje položky a publikuje `ZásobyRezervované`. Ak nie sú dostatočné, publikuje `RezerváciaZásobZlyhala`.
3. Platobná služba: Prihlási sa na odber `ZásobyRezervované`. Po prijatí udalosti spracuje platbu. Ak je úspešná, publikuje `PlatbaSpracovaná`. Ak zlyhá, publikuje `PlatbaZlyhala`.
4. Doručovacia služba: Prihlási sa na odber `PlatbaSpracovaná`. Po prijatí udalosti pripraví zásielku a publikuje `ZásielkaPripravená`.
5. Služba pre objednávky: Prihlási sa na odber `ZásielkaPripravená`. Po prijatí udalosti označí objednávku ako dokončenú.
6. Kompenzácia: Ak je publikovaná udalosť `PlatbaZlyhala` alebo `RezerváciaZásobZlyhala`, ostatné služby počúvajú a vykonávajú kompenzačné transakcie (napr. uvoľnenie rezervovaných zásob).

Výhody choreografie:

• Jednoduchosť: Jednoduchšia implementácia pre jednoduché pracovné postupy.
• Decentralizácia: Podporuje voľné prepojenie a nezávislý vývoj mikroslužieb.

Nevýhody choreografie:

• Zložitosť: Správa sa môže stať zložitou, keď sa zvyšuje počet účastníkov v Sage.
• Viditeľnosť: Je ťažké sledovať celkový priebeh a stav Sagy.
• Prepojenie: Hoci podporuje voľné prepojenie, služby stále musia byť oboznámené s udalosťami publikovanými inými službami.

2. Saga založená na orchestrácii

V Sage založenej na orchestrácii centrálny orchestrátor (často implementovaný ako dedikovaná služba alebo stavový automat) riadi Sagu a koordinuje vykonávanie lokálnych transakcií zúčastnenými mikroslužbami. Orchestrátor hovorí každej službe, čo má robiť a kedy to má urobiť.

Ako to funguje:

1. Saga začína, keď klient požiada orchestrátora o iniciovanie transakcie.
2. Orchestrátor posiela príkazy zúčastneným mikroslužbám, aby vykonali svoje lokálne transakcie.
3. Každá mikroslužba vykoná svoju transakciu a informuje orchestrátora o úspechu alebo zlyhaní.
4. Na základe výsledku sa orchestrátor rozhodne, či pokračovať na ďalší krok alebo iniciovať kompenzačné transakcie.

Príklad: Vytvorenie objednávky v e-shope (Orchestrácia)

1. Orchestrátor objednávok: Prijme novú požiadavku na objednávku.
2. Orchestrátor objednávok: Pošle príkaz Skladovej službe na rezerváciu položiek.
3. Skladová služba: Rezervuje položky a informuje Orchestrátor objednávok.
4. Orchestrátor objednávok: Pošle príkaz Platobnej službe na spracovanie platby.
5. Platobná služba: Spracuje platbu a informuje Orchestrátor objednávok.
6. Orchestrátor objednávok: Pošle príkaz Doručovacej službe na prípravu zásielky.
7. Doručovacia služba: Pripraví zásielku a informuje Orchestrátor objednávok.
8. Orchestrátor objednávok: Označí objednávku ako dokončenú.
9. Kompenzácia: Ak ktorýkoľvek krok zlyhá, Orchestrátor objednávok pošle kompenzačné príkazy príslušným službám (napr. uvoľnenie rezervovaných zásob).

Výhody orchestrácie:

• Centralizovaná kontrola: Jednoduchšie spravovanie a monitorovanie Sagy z jedného centrálneho bodu.
• Zlepšená viditeľnosť: Orchestrátor poskytuje jasný prehľad o celkovom priebehu a stave Sagy.
• Znížené prepojenie: Mikroslužby potrebujú komunikovať iba s orchestrátorom, čo znižuje priame závislosti medzi nimi.

Nevýhody orchestrácie:

• Zložitosť: Počiatočná implementácia môže byť zložitejšia, najmä pre jednoduché pracovné postupy.
• Jediný bod zlyhania (Single Point of Failure): Orchestrátor sa môže stať jediným bodom zlyhania, aj keď toto riziko sa dá zmierniť redundanciou a opatreniami na odolnosť voči chybám.

Implementácia kompenzačných transakcií

Kľúčovým aspektom vzoru Saga je implementácia kompenzačných transakcií. Tieto transakcie sa vykonávajú na zrušenie účinkov predtým dokončených transakcií v prípade zlyhania. Cieľom je vrátiť systém späť do konzistentného stavu, aj keď celú Sagu nemožno dokončiť.

Kľúčové aspekty kompenzačných transakcií:

• Idempotencia: Kompenzačné transakcie by mali byť idempotentné, čo znamená, že môžu byť vykonané viackrát bez zmeny výsledku. Toto je dôležité, pretože zlyhania sa môžu vyskytnúť kedykoľvek a kompenzačná transakcia sa môže opakovane skúšať.
• Spracovanie zlyhaní: Kompenzačné transakcie môžu tiež zlyhať. Musíte mať stratégiu na spracovanie zlyhaní v kompenzačných transakciách, ako je opakovanie pokusov, zaznamenávanie chýb a upozorňovanie administrátorov.
• Konzistencia dát: Kompenzačné transakcie by mali zabezpečiť, že dáta zostanú konzistentné. To môže zahŕňať obnovenie dát do predchádzajúceho stavu, vymazanie novovytvorených dát alebo aktualizáciu dát tak, aby odrážali zrušenie transakcie.

Príklady kompenzačných transakcií:

• Skladová služba: Ak Skladová služba rezervovala položky, ale platba zlyhala, kompenzačnou transakciou by bolo uvoľnenie rezervovaných položiek.
• Platobná služba: Ak Platobná služba spracovala platbu, ale doručenie zlyhalo, kompenzačná transakcia by mohla zahŕňať vrátenie peňazí.

Výzvy a úvahy

Hoci vzor Saga ponúka významné výhody, prináša aj niektoré výzvy a úvahy:

• Zložitosť: Implementácia vzoru Saga môže byť zložitá, najmä pre zložité obchodné procesy. Nevyhnutné je starostlivé plánovanie a návrh.
• Eventuálna konzistencia: Vzor Saga poskytuje eventuálnu konzistenciu, čo znamená, že dáta môžu byť dočasne nekonzistentné. To môže byť problém pre aplikácie, ktoré vyžadujú silné záruky konzistencie.
• Testovanie: Testovanie Ság môže byť náročné kvôli ich distribuovanej povahe a potenciálu zlyhaní v rôznych bodoch.
• Monitorovanie: Monitorovanie priebehu a stavu Ság je kľúčové pre identifikáciu a riešenie problémov. Musíte mať zavedené vhodné nástroje a procesy na monitorovanie.
• Idempotencia: Zabezpečenie, že transakcie a kompenzačné transakcie sú idempotentné, je kľúčové na predchádzanie nekonzistentnosti dát.
• Izolácia: Keďže Sagy zahŕňajú viacero lokálnych transakcií, izolácia môže byť problémom. Môžu byť potrebné stratégie ako sémantické zámky alebo optimistické zamykanie.

Prípady použitia a príklady

Vzor Saga je vhodný pre rôzne prípady použitia, najmä v distribuovaných systémoch a architektúrach mikroslužieb. Tu sú niektoré bežné príklady:

• Správa objednávok v e-shope: Ako je uvedené v príkladoch vyššie, vzor Saga sa dá použiť na správu celého životného cyklu objednávky, od jej vytvorenia cez spracovanie platby až po doručenie.
• Finančné transakcie: Vzor Saga sa dá použiť na správu zložitých finančných transakcií, ktoré zahŕňajú viacero systémov, ako sú prevody prostriedkov, žiadosti o úver a poistné udalosti.
• Riadenie dodávateľského reťazca: Vzor Saga sa dá použiť na koordináciu aktivít medzi viacerými subjektmi v dodávateľskom reťazci, ako sú výrobcovia, distribútori a maloobchodníci.
• Zdravotnícke systémy: Vzor Saga sa dá použiť na správu záznamov o pacientoch a koordináciu starostlivosti medzi rôznymi oddeleniami a poskytovateľmi.

Príklad: Globálna banková transakcia

Predstavte si scenár zahŕňajúci globálnu bankovú transakciu medzi dvoma rôznymi bankami v rôznych krajinách, ktoré podliehajú rôznym reguláciám a kontrolám zhody. Vzor Saga môže zabezpečiť, že transakcia bude prebiehať podľa definovaných krokov:

1. Iniciovanie transakcie: Zákazník iniciuje prevod prostriedkov zo svojho účtu v Banke A (so sídlom v USA) na účet príjemcu v Banke B (so sídlom v Nemecku).
2. Banka A - Validácia účtu: Banka A overí účet zákazníka, skontroluje dostatok prostriedkov a uistí sa, že na účte nie sú žiadne blokácie alebo obmedzenia.
3. Kontrola zhody (Banka A): Banka A vykoná kontrolu zhody, aby sa uistila, že transakcia neporušuje predpisy proti praniu špinavých peňazí (AML) ani žiadne medzinárodné sankcie.
4. Prevod prostriedkov (Banka A): Banka A odpíše prostriedky z účtu zákazníka a pošle ich do zúčtovacieho centra alebo sprostredkovateľskej banky.
5. Spracovanie v zúčtovacom centre: Zúčtovacie centrum spracuje transakciu, vykoná konverziu meny (USD na EUR) a presmeruje prostriedky do Banky B.
6. Banka B - Validácia účtu: Banka B overí účet príjemcu a uistí sa, že je aktívny a oprávnený prijímať prostriedky.
7. Kontrola zhody (Banka B): Banka B vykoná vlastnú kontrolu zhody v súlade s nemeckými a európskymi predpismi.
8. Pripísanie na účet (Banka B): Banka B pripíše prostriedky na účet príjemcu.
9. Potvrdenie: Banka B pošle potvrdzovaciu správu Banke A, ktorá následne informuje zákazníka, že transakcia je dokončená.

Kompenzačné transakcie:

• Ak kontrola zhody v Banke A zlyhá, transakcia je zrušená a z účtu zákazníka sa neodpíšu prostriedky.
• Ak kontrola zhody v Banke B zlyhá, prostriedky sa vrátia do Banky A a pripíšu sa späť na účet zákazníka.
• Ak sa vyskytnú problémy s konverziou meny alebo smerovaním v zúčtovacom centre, transakcia sa obráti a prostriedky sa vrátia do Banky A.

Nástroje a technológie

Pri implementácii vzoru Saga môže pomôcť niekoľko nástrojov a technológií:

• Fronty správ: Apache Kafka, RabbitMQ a Amazon SQS sa môžu použiť na publikovanie a odoberanie udalostí v Sage založenej na choreografii.
• Workflow enginy: Camunda, Zeebe a Apache Airflow sa môžu použiť na implementáciu orchestrátorov a správu zložitých pracovných postupov.
• Event Sourcing: Event Sourcing sa môže použiť na sledovanie histórie udalostí v Sage a uľahčenie vrátenia zmien v prípade zlyhania.
• Správcovia distribuovaných transakcií: Niektorí správcovia distribuovaných transakcií, ako je Atomikos, sa môžu použiť na koordináciu transakcií naprieč viacerými službami. Avšak, nemusia byť vhodné pre všetky architektúry mikroslužieb kvôli ich inherentným obmedzeniam v distribuovaných prostrediach.
• Frameworky pre Sagu: Existujú aj frameworky pre Sagu, ktoré poskytujú abstrakcie a nástroje na implementáciu vzoru Saga.

Osvedčené postupy pre implementáciu vzoru Saga

Pre efektívnu implementáciu vzoru Saga zvážte nasledujúce osvedčené postupy:

• Starostlivý návrh: Dôkladne analyzujte svoje obchodné požiadavky a navrhnite Sagu podľa nich. Identifikujte zúčastnené mikroslužby, sekvenciu transakcií a kompenzačné akcie.
• Idempotencia: Zabezpečte, aby všetky transakcie a kompenzačné transakcie boli idempotentné.
• Spracovanie chýb: Implementujte robustné mechanizmy na spracovanie chýb, aby ste zvládli zlyhania v ktoromkoľvek bode Sagy.
• Monitorovanie a zaznamenávanie: Implementujte komplexné monitorovanie a zaznamenávanie na sledovanie priebehu a stavu Ság.
• Testovanie: Dôkladne testujte svoje Sagy, aby ste zabezpečili ich správne fungovanie a elegantné zvládanie zlyhaní.
• Sémantické zámky: Implementujte sémantické zámky, aby ste zabránili súbežným aktualizáciám rovnakých dát rôznymi Sagami.
• Optimistické zamykanie: Použite optimistické zamykanie na detekciu a prevenciu konfliktov medzi súbežnými transakciami.
• Vyberte správnu implementačnú stratégiu: Starostlivo zvážte kompromisy medzi choreografiou a orchestráciou a vyberte si stratégiu, ktorá najlepšie vyhovuje vašim potrebám.
• Definujte jasné kompenzačné politiky: Stanovte jasné pravidlá pre spracovanie kompenzácií, vrátane podmienok, za ktorých sa kompenzácia spúšťa, a konkrétnych akcií, ktoré sa majú vykonať.

Záver

Vzor Saga je mocný nástroj na správu distribuovaných transakcií v architektúrach mikroslužieb. Rozdelením transakcií na sériu menších, nezávislých transakcií a poskytnutím mechanizmu na kompenzáciu zlyhaní vám vzor Saga umožňuje udržiavať konzistenciu dát a budovať odolné, škálovateľné a voľne prepojené systémy. Hoci implementácia vzoru Saga môže byť zložitá, výhody, ktoré ponúka v oblasti flexibility, škálovateľnosti a odolnosti, z neho robia cenný prínos pre akúkoľvek architektúru mikroslužieb.

Pochopenie nuáns vzoru Saga, kompromisov medzi choreografiou a orchestráciou a dôležitosti kompenzačných transakcií vám umožní navrhovať a implementovať robustné distribuované systémy, ktoré spĺňajú požiadavky dnešných zložitých podnikateľských prostredí. Prijatie vzoru Saga je krokom k budovaniu skutočne odolných a škálovateľných architektúr mikroslužieb, schopných s istotou zvládnuť aj tie najzložitejšie distribuované transakcie. Nezabudnite pri aplikácii tohto vzoru zvážiť vaše špecifické potreby a kontext a neustále zdokonaľovať svoju implementáciu na základe skúseností z reálneho sveta a spätnej väzby.